1. Field of the Invention
The present invention relates to the automation of electronic commerce conducted over a network. More particularly, the invention is directed to techniques for coordinating the exchange of information between transaction partners in order to facilitate the selection and acquisition of goods, services or other subject matter by client entities from supplier entities.
2. Description of the Prior Art
By way of background, the use of communications networks for electronic transactions has become pervasive. In the current state of the Internet, many suppliers of goods, services or other subject matters maintain websites that enable clients to obtain information about supplier offerings, such as identifications of the products, services, or other subject matters being offered, together with their price, availability, etc., and to execute online purchases or other trading transactions. Such suppliers are also increasingly implementing automated web or email service interfaces that facilitate automated trading. These interfaces allow clients to write automated trading applications that can interact with supplier services without human intervention. A typical client automated trading application executes on a general-purpose computer that is connected to the Internet. The client application communicates with a supplier's web or application server running the automated service interface. By selectively invoking desired service features according to its programming logic, the client application is able to conduct online transactions with the supplier server in automated fashion.
The foregoing automation is supported by languages, protocols and specifications such as WSDL (Web Service Definition Language), SOAP (Simple Object Access Protocol) and UDDI (Uniform Description Discovery and Integration). The WSDL language provides a standard mechanism for describing an automated service interface as a set of operations that clients can invoke to facilitate product or service acquisition. By way of example, the operations of a typical automated service interface could allow clients to (1) request a list of products or services, (2) obtain their price and availability, and (3) execute trading transactions. Using WSDL, suppliers can publish detailed specifications of such service operations that clients can use to write the automated trading applications that invoke those services.
The SOAP protocol provides an underlying communication mechanism by which automated trading applications can access the service operations defined in a WSDL specification. The protocol is based on the implementation of service operations as objects that remote applications can interact with using standardized request-response messaging dialogs. Each SOAP message is an XML (extensible Markup language) document that can be sent via HTTP (HyperText Transport Protocol) or SMTP (Simple Mail Transport Protocol). Thus, when a client automated trading application requires a list of products or services from a supplier, the client application can send the supplier's server an XML document containing a SOAP request message. This message will invoke the supplier object associated with the requested (WSDL-defined) service operation. After processing the request, the supplier's server will send the client an XML document containing a SOAP response message. This message will contain the requested information generated by the service operation object.
The UDDI specification provides a mechanism by which parties with electronic commerce capability can register information about their services in a public registry that is similar in function to a Yellow Pages directory for telephone networks. A party that maintains an online presence can register a profile of itself and its online trading capabilities, and query the profiles of other parties to identify potential trading partners.
Although client-side automation of supplier service interaction is preferable to manual techniques, one disadvantage from the client's perspective is that clients must often consult several potential suppliers to identify the most suitable candidate for providing a product or service of interest. For example, a computer maker requiring memory chips to build its computers may contact the websites of several chip suppliers in order to find the supplier that can best satisfy the client's needs.
Each such supplier will typically provide its own set of supplier service operations. This means that the client cannot write just one automated trading application to interact with the various automated service interfaces of all the suppliers, and will need to deal with each of them individually. In some cases a client needs to acquire several items, and each of the items may be associated with different groups of suppliers. This exacerbates the automation problem by multiplying the number of automated service interfaces exposed to the client. At this point, the automation of supplier service interaction may be more of a burden than a convenience.
It would be desirable, therefore, to provide a technique whereby automated supplier service interaction could be implemented more efficiently on behalf of clients. What is needed is a solution that allows clients to write a minimal number of automated trading applications while maximizing the number of suppliers whose automated service interfaces can be accessed by such applications.